## Summary
### Why?

The message queue topic-binding proto option was named `topics`, which
reads as a concrete wire topic name. It is not — it carries a stable
**logical topic key**. Each implementer maps the key to whatever topic
name its broker/queue requires (subject to that backend's naming
constraints); on our Go side the keys are `consumer.TopicKey` values,
mapped to concrete names through `TopicRegistry`. The name `topics`
invited the wrong mental model.

### What?

Rename the `google.protobuf.MessageOptions` extension `topics` →
`topic_keys` (field number `50001` unchanged, so the wire/extension
layout is identical) and reframe its doc comment to say it carries a
logical key, not a wire name. Regenerated `messagequeue.pb.go`
(`E_Topics` → `E_TopicKeys`).

This is the base of a stack; the runway contract and the contract RFC
that consume the option are updated in the branches stacked on top.

## Test Plan
✅ `make proto` — descriptor field renamed (`name=topics` →
`name=topic_keys`), field number `50001` unchanged
✅ `./tool/bazel build //...`

## Issues


## Stack
1. @ #264
1. #259
1. #260
1. #245
1. #247

## Summary
### Why?

Queue payloads are Go structs serialized with `encoding/json`, so the
wire shape is defined only by Go source. There is no language-neutral
contract a non-Go client can compile against, no explicit
topic-to-payload binding, and no distinction between a domain's private
wiring and a published cross-domain contract.

### What?

Doc-only — the design of record for message queue contracts
(`doc/rfc/messagequeue-contract.md`):

- **Contract language: Protobuf**, serialized as **protobuf JSON**
(`protojson`) so payloads stay self-describing JSON on the wire. The
`.proto` is the authority and the Go binding is generated from it, so it
cannot drift (no hand-authored struct, no drift test to keep them in
sync).
- **Topic binding:** a custom `topics` proto option (defined in
`api/base/messagequeue`) carries the wire topic names on the message
itself, read back by reflection — not on the publish/consume hot path,
which still resolves topics from a `consumer.TopicKey` via the registry.
- **Location by audience:** external contracts (something outside the
owning domain depends on them) live in `api/{domain}/messagequeue/`;
internal ones in `{domain}/core/messagequeue/`, with the split enforced
by Bazel `visibility`.
- Documents the accepted protojson conventions (snake_case field names,
UPPER_SNAKE enums, int64-as-string) and why JSON Schema, binary proto,
and Avro were rejected.

## Test Plan
- ✅ `make lint` (doc-only)

## Issues


## Stack
1. #264
1. @ #259
1. #260
1. #245
1. #247

## Summary
### Why?

Runway's merge queues are the first cross-domain message queue contract:
a client (potentially non-Go) publishes a merge request and consumes the
result without access to Runway's Go types or storage. Per the RFC
(#259) this needs a language-neutral, proto-defined contract.

### What?

Establishes the message queue contract pattern using Runway's merge
queues as the reference:

- Adds `api/runway/messagequeue/proto/merge.proto` defining
`MergeRequest`/`MergeResult`, reusing the shared `Change` and `Strategy`
types and the `topics` option from `api/base`; generated into `protopb`.
- Payloads are serialized as **protobuf JSON** via thin `protojson`
helpers (`MergeRequestToBytes`/`MergeRequestFromBytes` and the
`MergeResult` counterparts); a `Topics()` reflection helper exposes the
topic binding. Topic keys are co-located with the contract.
- Moves the merge bindings out of `runway/entity` into
`api/runway/messagequeue`.
- A drift test round-trips the payloads and asserts every Runway topic
key is bound to exactly one message via the `topics` option.

## Test Plan
- ✅ `./tool/bazel test //api/runway/messagequeue:messagequeue_test`
- ✅ `./tool/bazel build //...`

## Issues


## Stack
1. #264
1. #259
1. @ #260
1. #245
1. #247

## Summary
### Why?

The committing merge ran synchronously inside the orchestrator, blocking
the partition lease on a slow, I/O-heavy operation and coupling
SubmitQueue to the merger's latency. This moves the merge to an
asynchronous round-trip with Runway — mirroring the merge-conflict check
(#245), but for the committing merge.

### What?

Adds `batch → merge ⇢ (runway) ⇢ mergesignal → conclude/speculate`:

- `merge` (new) consumes a batch ready to land, builds the full
`MergeRequest` from the batch's member requests (one `MergeStep` per
request in Contains order, carrying each request's change and land
strategy), and publishes it to Runway's `merger` queue keyed by the
batch id as the client-owned correlation id.
- `mergesignal` (new) consumes Runway's `MergeResult` off
`merger-signal`, correlates by the echoed id, and transitions the batch
to `Succeeded` (merged) or `Failed` (could not) — then fans out to
`conclude` (so member requests pick up the outcome) and `speculate` (so
dependents can re-plan). Purely result-driven; no poll loop.
- DLQ reconcilers drive the batch to a terminal state on dead-letter.

Reuses the Runway merge contract from #260 — the same
`MergeRequest`/`MergeResult`, carried on the committing
`merger`/`merger-signal` topics rather than the dry-run check topics.
Runway's service implementation is out of scope.

## Test Plan
- ✅ `./tool/bazel build //...`
- ✅ `./tool/bazel test //... --test_tag_filters=-integration,-e2e` (57
tests pass)

## Issues


## Stack
1. #264
1. #259
1. #260
1. #245
1. @ #247